Claude Code 攻略 2.1 - 从闭环到 Agent：深入理解 Claude Code 的架构设计

Claude Code 是什么#

在深入架构之前,我先说说我对 Claude Code 的初步认识:它是一个将 LLM 作为大脑、工具系统(bash、MCP、HTTP 等)作为肢体的 AI 应用。

和传统 AI 工具相比,它的核心差异在于:

利用工具系统自动获取环境所需的信息,无需手动注入上下文
自动根据任务设计方案,循环执行直到完成交付标准

这个认知听起来简单,但背后的设计思想值得深入理解。

闭环系统:重新定义 AI 编程助手#

传统 AI 工具的开环流程#

传统 AI 工具(如 ChatGPT)的工作流程是开环的:

用户收集上下文内容
  ↓
粘贴到对话框,整理需求并发送
  ↓
AI 理解上下文,给出答案
  ↓
一轮对话结束

这个流程能做到的只是:根据用户提供的信息给出一个可能不全面的方案。

问题在哪里?

上下文收集依赖人工,容易遗漏关键信息
信息在"复制粘贴"过程中损耗
方案给出后,执行和验证仍需人工完成
如果有问题,需要重新整理信息再次询问

这是一个开环系统:输入 → 输出,然后结束。

Claude Code 的闭环设计#

Claude Code 的流程完全不同:

用户说出需求
  ↓
Claude Code 根据需求,利用工具系统自动读取项目内容
  ↓
基于完整上下文给出方案
  ↓
利用工具系统直接执行(修改文件、运行测试)
  ↓
自动验证结果(执行测试、检查编译)
  ↓
有问题?补充上下文,修改方案,再次执行
  ↓
循环直到结果符合标准

这是一个闭环系统:需求 → 执行 → 验证 → 反馈 → 调整 → 再执行。

信息流对比#

传统 AI 的信息流存在严重损耗:

实际代码/错误
  ↓
[人工理解] → 简化描述
  ↓
[粘贴到对话框] → AI 理解
  ↓
[AI 生成答案] → 代码/建议
  ↓
[人工复制] → [人工执行]
  ↓
结果/错误
  ↓
[人工理解] → 再次简化描述...

每一步都有信息损耗,就像"传话游戏"

Claude Code 的信息流几乎零损耗:

实际代码/错误
  ↓
[工具系统直接读取] → AI 分析
  ↓
[工具系统直接执行] → 结果/错误
  ↓
[工具系统直接读取] → AI 分析...

信息是"原汁原味"的

为什么"闭环"如此重要#

闭环系统的价值在于极大降低了信息对齐成本:

上下文质量提升

人工复制粘贴很难做到上下文的全面和准确
工具系统自动获取,提取相关信息,大幅提升了上下文质量

反馈即时准确

传统 AI 只能基于用户的再次反馈和反馈信息质量
Claude Code 可以第一时间获取具体的命令输出、错误堆栈,自动基于这些上下文进行修复

迭代成本降低

传统流程:人工理解错误 → 简化描述 → 等待 AI 回答 → 人工执行 → 再次循环
Claude Code 流程:自动检测错误 → 自动修复 → 自动验证 → 自动迭代

三层架构:闭环的完整实现#

实现闭环系统需要完整的架构设计。Claude Code 采用三层架构:

执行层:提供执行容器(主Agent和Subagent)、工具系统和安全保障
能力层:提供核心机制(Extended Thinking、Todo System等)和扩展能力(MCP、Skills、Hooks)
应用层:提供高级工作模式(Plan Mode和Subagent架构)

层级关系详解#

在深入每一层之前,先理解三层之间的关系非常重要。很多人会把 Subagent、MCP、Skills、Hooks 理解为同一层级的"扩展机制",但实际上它们处于不同的层次。

关键理解:Subagent 不是扩展机制,而是执行机制

┌─────────────────────────────────────────┐
│         执行层 (How to Execute)          │
├─────────────────────────────────────────┤
│  主 Agent                               │
│    ↓ 启动                               │
│  Subagent (独立上下文，并发执行)         │
└─────────────────────────────────────────┘
              ↓ 继承/访问
┌─────────────────────────────────────────┐
│         能力层 (What Can Do)             │
├─────────────────────────────────────────┤
│  系统工具 (内置)                         │
│  MCP Servers (扩展工具)                  │
│  Skills (扩展知识)                       │
│  Hooks (事件监听，自动触发)               │
└─────────────────────────────────────────┘
              ↓ 基于能力构建
┌─────────────────────────────────────────┐
│         应用层 (How to Organize)         │
├─────────────────────────────────────────┤
│  Plan Mode (先规划后执行)                │
│  Subagent 架构 (专业化协作)              │
└─────────────────────────────────────────┘

三层的关系:

执行层: Subagent 是执行容器,在独立上下文中运行任务
能力层: 提供 Agent 可以使用的工具、知识和机制(包括 Hooks)
应用层: 基于能力层构建的高级工作模式(Plan Mode 和 Subagent 架构)

实际执行流程#

让我们通过一个具体场景理解三层是如何协同工作的。

场景:使用 Subagent 探索代码库

// 主 Agent 的决策
主 Agent: "我需要探索前端代码,启动 Explore Subagent"

// Step 1: 启动 Subagent
启动 Explore Subagent {
  独立上下文: 新的 200K token 窗口

  继承的能力（自动配置）:
  ├─ 系统工具: Read, Glob, Grep, Bash (根据 Agent 类型配置)
  ├─ MCP 工具:
  │   └─ 如果配置了 filesystem MCP，可以访问
  ├─ Skills:
  │   └─ 如果有 react-performance Skill，自动加载
  └─ CLAUDE.md: 自动读取项目配置
}

// Step 2: Subagent 执行任务
Explore Subagent 执行:
  1. 读取传入的 prompt
  2. 使用继承的工具:
     - Glob 查找文件
     - Grep 搜索代码
     - Read 读取文件
     - (如果配置了 MCP) 调用 MCP 工具
  3. 使用继承的知识:
     - (如果有 Skills) 应用分析框架
  4. 生成结果

// Step 3: Hooks 的独立触发（与 Subagent 并行）
Hooks 监听事件:
  - PreToolUse: 在 Subagent 调用 Read 前触发
  - PostToolUse: 在 Subagent 调用 Read 后触发
  - (这些是自动的，不是 Subagent 主动调用)

// Step 4: 返回结果
Subagent 完成 → 返回给主 Agent

关键点:

Subagent 继承能力,不是"调用"能力
MCP 和 Skills 对 Subagent 是透明的,就像系统工具一样
Hooks 监听事件,不是被"调用"
三个层次各司其职:执行层(运行容器) → 能力层(工具和机制) → 应用层(工作模式)

类比帮助理解#

类比 1:操作系统进程#

主 Agent = 主进程
Subagent = 子进程 (fork)

子进程继承:
  ✅ 环境变量 (CLAUDE.md)
  ✅ 已打开的文件描述符 (MCP 连接)
  ✅ 共享库 (Skills 知识)

子进程不继承:
  ❌ 父进程的内存 (上下文隔离)
  ❌ 父进程的执行状态

信号处理器 = Hooks
  - 全局注册
  - 主进程和子进程都会收到信号

类比 2:浏览器标签页#

主 Agent = 当前标签页
Subagent = 新标签页

新标签页继承:
  ✅ 浏览器扩展 (MCP)
  ✅ Cookie (CLAUDE.md)
  ✅ 浏览器设置 (Skills)

新标签页不继承:
  ❌ 原标签页的浏览历史 (上下文)
  ❌ 原标签页的 DOM 状态

浏览器事件监听 = Hooks
  - 所有标签页的点击都会被监听
  - 不是标签页主动"调用"监听器

准确的理解:

当主 Agent 决定启动 Subagent 时,Subagent 会在独立的上下文中执行任务,同时自动继承全局配置的能力(系统工具 + MCP 工具 + Skills 知识 + CLAUDE.md)。Hooks 作为独立的事件监听系统,会在 Subagent 执行过程中的特定时机自动触发,而不是被 Subagent 主动调用。

下面我们逐层深入。

执行层:工具系统与权限模型#

执行层是闭环系统的基础设施,提供了 AI 与环境交互的能力,同时通过权限模型保障安全性。

工具系统:获取上下文、执行代码、验证结果#

Claude Code 的工具系统包括:

文件操作

Read - 读取文件内容
Write - 创建新文件
Edit - 修改现有文件
Glob - 文件模式匹配
Grep - 内容搜索

命令执行

Bash - 在沙箱环境中执行命令
可以运行测试、编译代码、执行脚本

Web 访问

WebSearch - 搜索网络信息
WebFetch - 获取网页内容

扩展工具(MCP)

数据库访问、API 集成、自定义工具

有了这些工具,AI 才能:

自动读取项目文件,获取完整上下文
直接修改代码,执行方案
运行测试和编译,验证结果

权限模型:平衡自动化与安全性#

既然 AI 能直接执行操作,那如果 AI 判断错误,直接删除了重要文件怎么办?

传统 AI 工具因为需要"人工执行",反而有了一道天然的"安全阀"。Claude Code 的闭环虽然高效,但也失去了这道安全阀。

Claude Code 的解决方案:权限系统

权限系统采用三层设计:

1. 风险分级(自动判断)

低风险(无需授权):
- Read、Glob、Grep - 只读操作
- git status、git log - 查看操作

中风险(需要授权):
- Write、Edit - 文件修改
- Bash 写操作 - 命令执行

高风险(需要明确确认):
- 删除文件
- git push --force
- 系统级命令

2. 灵活配置(用户控制)

在 .claude/settings.json 或 .claude/settings.local.json 中配置:

{
  "permissions": {
    "allow": [
      "Read(src/**)",
      "Write(src/**)",
      "Edit(src/**)",
      "Bash(git status:*)",
      "Bash(npm:*)"
    ],
    "ask": [
      "Bash(git add:*)",
      "Bash(git commit:*)"
    ]
  }
}

配置语法:

Bash(command:*) - 使用冒号分隔,* 表示匹配所有参数
Read(path) - 支持 glob 模式,如 src/** 或 **/*.env

需要注意的是,目前版本的 deny 权限存在漏洞,不会真正生效。推荐使用 allow 白名单策略,而不是 deny 黑名单。

3. 透明可见(建立信任)

操作前展示具体内容(要写什么、要执行什么)
失败后展示详细错误
一次性授权:"Allow once" / "Always allow for this session"

这套权限系统在"自动化效率"和"安全性"之间找到了平衡。

能力层:支撑闭环的核心机制#

有了工具和权限,AI 就能执行了。但如何保证执行的质量和可靠性?这需要核心机制的支撑。

能力层包括两部分:

核心机制:Extended Thinking、Todo System、迭代思维(本节重点)
扩展能力:MCP、Skills、Hooks(在后续攻略中详细讲解)

这些机制和能力共同保障了闭环系统的可靠性。下面重点介绍三个核心机制:

Extended Thinking:AI 的"草稿纸"#

问题:AI 能"先想好再说"吗?

回想 LLM 的工作方式:逐 token 生成,每生成一个字都基于之前的内容。这意味着 AI 在开始回答的第一个字时,就必须确定整个方案。

类比:你被要求"不打草稿,直接在答卷上写最终答案"。

场景:设计一个分布式任务调度系统

没有 Extended Thinking(普通模式):

用户提问
  ↓
AI 直接输出:"我建议使用Redis作为队列..."
  ↓
问题:第一个字写出来时,AI已经决定了整个方案
      没有"试错空间"来权衡不同方案的利弊

有 Extended Thinking(扩展思考模式):

用户提问
  ↓
AI 内部思考(对用户不可见):
  <thinking>
  方案A:Redis队列
    优点:简单、成熟
    缺点:持久化能力弱

  方案B:RabbitMQ
    优点:可靠性高、支持复杂路由
    缺点:学习成本高

  方案C:数据库轮询
    优点:不依赖额外组件
    缺点:性能差、扩展性弱

  权衡:方案B更适合,因为...
  </thinking>
  ↓
AI 输出最终方案:"我建议使用RabbitMQ..."

技术实现:

Extended Thinking 通过 <thinking> 块实现:

AI 先生成一个隐藏的思考块,可以在里面推演、对比、否定、修正
思考完成后,再生成正式回答
思考内容不占用对话历史(不污染上下文)

适用场景:

✅ 复杂架构设计、技术选型、深度代码分析
❌ 简单代码补全、快速问答

关于配置:

Extended Thinking 有默认值(通常 2000-4000 tokens),对大多数场景已足够。

使用建议:

日常使用:不设置,使用默认值
遇到复杂任务时:按需临时调整
```
MAX_THINKING_TOKENS=8000 claude-code
```

Todo System:AI 的"任务清单"#

问题:AI 如何避免"做着做着就忘了还有什么要做"?

场景:重构认证系统 + 添加 OAuth + 修复 bug

没有 Todo System:

用户:"重构认证系统,添加OAuth,修复session bug"
  ↓
AI 开始执行...
  ↓
用户心里:
- 它做到哪了?
- 还要多久?
- 会不会遗漏某个步骤?

有 Todo System:

用户:"重构认证系统,添加OAuth,修复session bug"
  ↓
AI 调用 TodoWrite 工具:
┌───────────────────────────────┐
│ [ ] 分析现有认证代码结构      │
│ [ ] 设计 OAuth 集成方案       │
│ [ ] 实现 OAuth 登录流程       │
│ [ ] 修复 session 过期 bug     │
│ [ ] 编写测试用例              │
│ [ ] 更新相关文档              │
└───────────────────────────────┘
  ↓
AI 开始执行第一步:
[🔄] 分析现有认证代码结构
[ ] 设计 OAuth 集成方案
...
  ↓
[✅] 分析现有认证代码结构
[🔄] 设计 OAuth 集成方案
...

技术实现:

Todo System 通过 TodoWrite 工具维护独立状态:

任务状态:pending(待开始)、in_progress(进行中)、completed(已完成)
核心规则:同时只有一个任务 in_progress(强制 AI 聚焦,避免分心)
不占用对话上下文(类似全局变量)

为什么"同时只有一个 in_progress"?

依赖关系:任务 B 可能依赖任务 A 的结果
AI 聚焦:一次只做一件事,避免分心
用户体验:清楚知道"当前在做什么"
避免冲突:多个任务同时修改同一文件会冲突

价值:

防止 AI "迷失":任务清单是"导航地图"
用户有掌控感:实时可见进度
长对话不遗忘:任务清单是"持久化的记忆",不受上下文长度影响

迭代思维:反馈驱动的循环#

问题:如何判断"已经达到交付标准"?

Claude Code 并不是真正"自主判断"任务是否完成,而是依赖两种反馈:

1. 客观反馈(工具执行结果)

场景:修复一个 TypeScript 类型错误

1. 读取错误信息
2. 修改代码
3. 运行 tsc --noEmit
4. 看到输出 "✅ No errors"
5. 结论:"任务完成"

2. 用户反馈(主观验证)

场景:优化一段代码的性能

1. 分析代码
2. 重构优化
3. 运行代码
4. ??? 没有性能测试,无法判断"性能已优化"
5. 提示用户:"我已经优化了代码,请验证一下性能是否提升"

核心机制:

有客观反馈 → 自动迭代直到反馈为正
无客观反馈 → 完成可做部分,交给用户验证

这不是"自主判断",而是反馈驱动的迭代。

三个机制的协同#

这三个机制共同构成了 Claude Code 的"可靠性保障":

Extended Thinking = 想清楚
  ↓
Todo System = 做有序
  ↓
迭代思维 = 做稳妥
  ↓
高质量结果

完整流程示例:重构 UserProfile 组件

用户:"重构UserProfile.tsx,拆分成多个小组件"
  ↓
┌────────────────────────────────────────┐
│ Extended Thinking(规划质量保障)       │
│ <thinking>                             │
│ 方案A:按UI层级拆分                     │
│   缺点:状态管理复杂                    │
│ 方案B:按业务逻辑拆分                   │
│   优点:职责清晰,状态独立               │
│ 结论:选方案B                           │
│ </thinking>                            │
└────────────────────────────────────────┘
  ↓
┌────────────────────────────────────────┐
│ Todo System(进度管理保障)              │
│ [🔄] 分析UserProfile.tsx代码结构       │
│ [ ] 设计组件拆分方案                   │
│ [ ] 创建UserInfo组件                   │
│ [ ] 创建Settings组件                   │
│ [ ] 重构UserProfile使用新组件          │
│ [ ] 运行测试验证功能                   │
└────────────────────────────────────────┘
  ↓
┌────────────────────────────────────────┐
│ 迭代思维(执行质量保障)                 │
│ 执行每个任务时:                        │
│   思考 → 行动 → 观察 → 调整            │
│   循环直到任务完成                     │
└────────────────────────────────────────┘

在架构中的位置:

这三个机制支撑了:

Plan Mode:依赖 Extended Thinking(规划质量) + Todo System(进度跟踪)
Subagent:每个 Agent 内部也用迭代思维执行任务
闭环执行:迭代思维让"执行-验证-调整"成为可能
长对话稳定性:Todo System 防止上下文漂移

应用层:先规划后执行的 Agent 架构#

基于核心机制,Claude Code 构建了两个高级工作模式:Plan Mode 和 Subagent 架构。

Plan Mode:为什么需要独立的规划阶段#

假设老板让你给项目添加"用户登录注册"功能。

直接开始写代码的问题(Cursor/直觉模式):

你打开编辑器,第一反应是什么?先写 login 接口?还是先设计数据库表?还是先实现前端表单?

当你写到第 3 步"实现 login API"时,大脑在想什么?还记得"需要更新文档"吗?

问题根源:上下文注意力的漂移

上下文演变:
[需求:添加用户认证]
  ↓ 开始写代码
[需求 + 第1步代码 + 报错信息]
  ↓ 修复错误
[需求 + 第1步代码 + 修复 + 新报错]
  ↓ 继续修复
[需求 + 一堆实现细节 + 错误信息 + ...]
  ↓ 上下文爆炸
忘记了"还需要更新文档"

注意力被"当前问题"吸走了。当你在调试"为什么 login 接口返回 500"时,大脑(或 AI)的注意力全在错误堆栈、代码细节、调试输出上。早期的"全局规划"被淹没在细节中。

先规划后执行的优势:

规划阶段(独立上下文):
[需求:添加用户认证]
  ↓ 只关注"需要做什么"
[完整的任务清单 + 依赖关系]
  ↓ 保存为文档

执行阶段(新的上下文):
[任务清单 + 当前任务 + 实现细节]
  ↓ 注意力聚焦在"怎么做"
[任务清单] ← 始终在上下文顶部
  ↓ 每完成一步,检查清单
"下一步:更新文档"

Plan Mode 的核心设计:上下文隔离

规划阶段:用独立的 Explore/Plan Agent
- 上下文只包含:项目结构 + 需求描述
- 不被实现细节干扰
- 输出:完整的任务清单
执行阶段:切换到新的上下文
- 读取之前保存的 plan 文件
- plan 文件始终在上下文顶部
- 每步执行完,回看 plan,决定下一步

Plan Mode 的完整工作流程#

Plan Mode 分为 5 个阶段:

Phase 1: Initial Understanding
  ↓
  理解用户需求,确认基本信息

Phase 2: Design (使用 Explore/Plan Agents)
  ↓
  Explore Agent:分析项目结构、找相关代码
  Plan Agent:基于探索结果,拆解任务

Phase 3: Review
  ↓
  AI 向用户展示计划,确认对齐

Phase 4: Final Plan
  ↓
  生成结构化的 plan 文档

Phase 5: Exit & Execute
  ↓
  退出 Plan Mode,按计划执行

Explore 和 Plan Agent:设计与分工#

在 Plan Mode 的 Phase 2 阶段,Claude Code 会启动专门的 Explore 和 Plan Agent 来完成探索和规划工作。

Explore Agent 的核心职责:

逐步缩小范围,自顶向下探索项目结构
定位与任务相关的关键文件和代码
在独立上下文中处理大量信息,提炼成精炼摘要
避免在主对话中污染上下文

Plan Agent 的核心职责:

基于 Explore Agent 的摘要,拆解任务
遵循单一职责、依赖顺序、可测试性原则
为每个步骤定义明确的验收标准
生成结构化的执行计划

Subagent 的设计价值:

通过上下文隔离,Explore 和 Plan Agent 能在独立环境中专注完成自己的任务,然后将精炼结果返回主对话。这种设计避免了:

主对话被大量探索细节淹没
规划思维被实现细节干扰
Token 成本无限制增长

关于这两个 Agent 的详细工作流程和使用技巧,会在后续的攻略 2.2 中深入讲解。

何时使用 Plan Mode#

Plan Mode 这么好,为什么不是默认开启?

成本收益分析:

场景	Plan Mode 成本	不用 Plan Mode 的风险	建议
小改动	Token + 时间	低	不用
中等任务	适中	中等(可能遗漏)	可选
复杂任务	适中	高(返工成本大)	必用

决策树:

任务复杂度判断:

├─ 单文件 + 明确修改点?
│   → 不需要 Plan Mode
│   例:修改一个函数的逻辑、修复拼写错误
│
├─ 多文件 + 依赖关系简单?
│   → 可选 Plan Mode(看个人习惯)
│   例:添加一个新的 API endpoint + 测试
│
└─ 多文件 + 复杂依赖 + 需要探索?
    → 强烈建议 Plan Mode
    例:重构模块、添加新功能、数据库迁移

核心判断标准:

需要探索项目结构吗?→ 需要就用
有多个步骤依赖吗?→ 有就用
容易遗漏关联修改吗?→ 容易就用

Subagent 架构:专业化协作#

Plan Mode 中我们已经接触过 Explore 和 Plan Agent,但 Subagent 的能力远不止于此。

为什么需要多种 Agent

Explore 和 Plan 是在"规划阶段"用的 Agent。执行阶段呢?

假设你用 Claude Code 完成了一个功能,代码已经写好了。接下来应该做什么?

代码审查(检查质量、规范、潜在问题)
运行测试(确保功能正确)
写文档(说明使用方法)

问题:写代码的 AI 和审查代码的 AI,应该是同一个吗?

就像人一样,自己检查自己的错误很难发现,这是一种惯性思维。如果换一个人/Agent 来做检查,就更容易发现潜在问题。

主对话写完代码后:

上下文包含:
- 需求理解
- 设计思路
- 实现过程
- 遇到的问题和解决方案

思维惯性:
- "这里我是故意这么写的"
- "这个边界情况我考虑过了"
- "这个变量名虽然不完美,但能理解"

Code-reviewer Agent(独立上下文):

上下文包含:
- 代码本身
- 项目规范
- 最佳实践

没有"写代码时的思维惯性":
- "这个函数太长了,应该拆分"
- "这个边界情况没有测试覆盖"
- "这个变量名不符合项目命名规范"

这就是 Subagent 设计的核心思想:专业化分工 + 避免认知盲区

Agent 类型与职责

Claude Code 提供了 30+ 种专业化 Agent:

规划类 Agent

Explore Agent:探索代码库、理解项目结构
Plan Agent:任务拆解、定义验收标准

质量保障类 Agent

Code-reviewer Agent:代码审查、发现潜在问题
Test-automator Agent:生成测试用例、提升覆盖率
Debugger Agent:分析错误、定位问题根因

专业领域类 Agent

Frontend-developer Agent:React/Vue 组件开发、响应式布局
Backend-architect Agent:API 设计、数据库 schema、架构评审
Database-optimizer Agent:SQL 优化、索引设计、查询性能
... 还有更多

使用方式:

Claude Code 主动建议(完成代码后自动启动 Code-reviewer)
你手动请求("审查一下刚才写的代码")
明确指定 Agent("用 code-reviewer agent 检查一下这段代码")

上下文隔离与传递#

核心问题:

主对话的上下文有 20 轮对话、10 个文件,Code-reviewer Agent 启动时能看到这些内容吗?

答案:部分可见

Subagent 启动时会接收:

任务描述(主对话告诉它要做什么)
相关文件(主对话指定需要审查哪些文件)
项目配置(CLAUDE.md、tsconfig.json 等)

但不包含:

主对话的完整历史
中间的实现细节
错误和调试过程

这是故意的设计:

保持 Agent 专注于任务
避免被无关信息干扰
节省 Token 成本

传递机制示例:

主对话完成任务后:
  ↓
检测到文件变更(通过 git diff 或内部追踪)

修改的文件:
- src/auth/login.ts
- src/auth/register.ts
- src/middleware/auth.ts
- tests/auth.test.ts
- README.md
  ↓
启动 Code-reviewer Agent,传递:
{
  task: "审查刚才的代码修改",
  files: [
    { path: "src/auth/login.ts", diff: "..." },
    { path: "src/auth/register.ts", diff: "..." },
    ...
  ],
  context: {
    projectType: "Next.js",
    testFramework: "Jest",
    ...从 CLAUDE.md 读取的配置
  }
}
  ↓
Code-reviewer Agent 的上下文:
- 只看到这 5 个文件的 diff
- 不知道"为什么改"的完整对话历史
- 专注于代码质量本身

传递策略:智能混合

如果修改很小(< 50 行):
  → 传递完整文件(提供更多上下文)

如果修改较大(> 50 行):
  → 传递 diff + 关键周边代码

如果涉及多个文件:
  → 每个文件单独评估策略

并发执行策略#

Subagent 的另一个强大能力:并发。

场景:重构一个大型模块

传统方式(串行):

1. 探索 auth 模块代码    [5 分钟]
2. 探索 database 模块代码 [5 分钟]
3. 探索 API 模块代码     [5 分钟]
总耗时:15 分钟

Subagent 并发:

同时启动 3 个 Explore Agent:
  Agent-1: 探索 auth 模块    [5 分钟]
  Agent-2: 探索 database 模块 [5 分钟]
  Agent-3: 探索 API 模块     [5 分钟]
总耗时:5 分钟(并发执行)

如何并发:

对话中明确指示:"同时探索这三个模块的代码:auth、database、API"
Claude Code 自动判断任务可以拆分,一次性启动多个 Agent

推荐并发数:1-3 个 Agent

过多并发会降低性价比。

局限性#

Subagent 虽然强大,但也有限制:

Agent 之间无法直接通信
- Agent-1 无法告诉 Agent-2:"我发现了一个问题"
- 只能通过"主对话"协调
每个 Agent 的上下文有限
- Agent 无法访问主对话的完整历史
- 只能看到主对话传递的信息
Agent 启动有成本
- Token(上下文初始化)
- 时间(等待 Agent 完成)
- API 调用次数
并发数量有限
- 推荐 1-3 个并发
- 10+ 个 Agent 性价比低

定位对比:与其他工具的差异#

理解了完整的三层架构,我们再来看 Claude Code 与其他工具的差异会更清晰。

vs ChatGPT:闭环 vs 开环#

维度	ChatGPT	Claude Code
信息来源	用户手动粘贴	工具自动获取
执行能力	无,只能给建议	有,直接修改代码
反馈机制	无,用户手动验证	有,自动执行测试/编译
迭代模式	一次性回答	反馈驱动的循环
完成标准	给出答案即结束	客观反馈为正或用户确认

本质差异:

ChatGPT:开环系统,输入 → 输出,结束
Claude Code:闭环系统,输入 → 行动 → 观察 → 调整 → 行动...

vs Copilot:全流程 vs 单点补全#

Copilot 的工作模式:

我写一段注释或函数名
Copilot 根据这个信息自动生成后面几行代码

这只是在传统 AI 对话过程中,提高了一个环节的上下文效率。

Copilot 优化的环节(单点突破):
理解需求(人) → 规划方案(人) → [写代码(AI)] → 验证(人) → 调整(人)
                                  ↑
                            只有这一步是 AI

Claude Code 优化的环节(全流程):
理解需求(人) → [规划方案(AI) → 写代码(AI) → 验证(AI) → 调整(AI)]
                ↑_____________闭环系统_____________↑

定位差异:

Copilot:增强的代码补全工具
Claude Code:真正的软件开发 Agent

vs Cursor:系统化 vs 直觉式#

Cursor 介于 Copilot 和 Claude Code 之间:

Cursor 有的:

多文件编辑(能同时修改多个文件)
代码库理解(能分析整个项目)
对话式交互(像 ChatGPT 一样聊天)
自动执行命令(可以运行 bash 命令)

Cursor 没有的(相比 Claude Code):

Plan Mode:没有独立的"规划阶段",直接就开始写代码
Subagent:没有专业化分工,一个 AI 处理所有任务
系统化的迭代验证:不会自动"测试 → 失败 → 修复 → 再测试"这样循环

场景对比:给大型项目添加新功能

Cursor 的流程:

用户:"帮我添加用户认证功能"
  ↓
Cursor 直接开始改代码
  ↓
改了 10 个文件
  ↓
"完成了,你测试一下吧"
  ↓
用户运行发现:
- 数据库 schema 没更新
- 某个依赖文件遗漏了
- 测试文件没有对应更新

Claude Code 的流程:

用户:"帮我添加用户认证功能"
  ↓
进入 Plan Mode
  ↓
Explore Agent 分析项目结构
Plan Agent 拆解任务:
  1. 更新数据库 schema
  2. 实现 auth 中间件
  3. 修改路由配置
  4. 添加测试
  5. 更新文档
  ↓
用户审查计划:"好的,开始执行"
  ↓
按步骤执行,每步验证
  ↓
最终测试通过才算完成

缺少 Plan Mode 的问题: